1. Field of the Invention
The invention relates to a method and apparatus for bridging between networks. More particularly, the invention relates to a method and apparatus for connecting computer networks of dissimilar types.
2. Description of the Related Art
This text refers to IEEE standards, Requests for Comments (RFCs) and Internet-Drafts. These are all standard sources in the networking field. IEEE standards are published by the Institute of Electrical and Electronics Engineers, Inc., 345 East 47th Street, New York, N.Y. 10017, USA. RFCs are a series of notes about the Internet, and include the specification documents of protocols associated with the Internet as these are defined by the Internet Engineering Task Force (IETF). RFCs are published by the Information Sciences Institute (ISI) of the University of Southern California (USC). Internet-Drafts are working documents of the Internet Engineering Task Force (IETF) and its working groups (and of certain other bodies) and may form the basis for later RFCs. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. Both RFCs and current Internet-Drafts are obtainable through the World Wide Web site of the IETF, http://www.ietf.org/.
Computer networking is complex, and for practical tractability is divided into a number of subtasks. Conventionally, a network is divided into layers, with each layer being responsible for providing a service to the layer above it, the layer itself calling on the services of the layer below it.
The generally accepted model for networking is the OSI (Open Systems Interconnection) Reference Model defined by ISO. This defines seven layers, as are illustrated in FIG. 1. Each layer 1 at a node 4 communicates with its peer layer 1 at another node through the use of a protocol 2. Such communication is accomplished through direct communication with the layer below. The communication 3 between overlying layers is known as an interface.
The layers as defined in the OSI are as follows.
Physical layer This operates to transit unstructured bits of information across a link. It is relevant to similar fundamental structural arrangements such as connector type and identification of the purpose of different wires in a cable.
Data link layer This operates to transmit basic structural blocks of information across a link This is the critical layer for communication within a local area network (LAN), and deals with addressing within a LAN, for example. A sublayer of the data link layer is the medium access control (MAC) layer, which addresses issues specific to a particular type of LAN.
Network layer This operates so as to enable any pair of systems in the network to communicate with each other. The dominant network layer protocol is the Internet Protocol (IP). The network layer is responsible for issues such as route calculation and packet fragmentation and reassembly.
Transport layer This operates to achieve a reliable communication stream between two systems. The transport layer deals with issues such as lost packets and packet reordering.
Session layer, Presentation layer, Application layer These are used for higher level services (particular communication patterns, data representations, standardization of applications) and are not relevant to the communication issues under consideration here.
Communication within a single LAN is handled by the data link layer. A basic problem in networking is communication between two or more LANs, or between a LAN and a network backbone. If two LANs to be connected together are of the same type or sufficiently similar and share the same MAC level addressing, then a bridge can be used to link the LANs together. A bridge is a device which connects two LANs (or, rather, nodes on two LANs) at the level of the data link layer. IEEE 802.1d is a standard defining such bridges (termed “transparent” bridges, because nodes on the network are unaware of the existence of such bridges, the nodes “seeing” other nodes directly across the bridge)—bridges not conforming to the IEEE 802.1d can of course be constructed, but are not standard network components. The operation of a basic bridge is described below with reference to FIG. 2.
The bridge 21 connects two LAN segments. 22, 23, accessing each segment via a separate port 25, 26. Each LAN segment has a number of nodes 24. The bridge 21 listens to every packet transmitted on either of the LAN segments 22 and 23. For each packet received, the bridge stores the MAC address in the packet's source address field in a cache, together with the port on which the packet is received. The bridge 21 then looks through its cache to find the MAC address in the packet's destination address field. If the destination address is not found in the cache, the packet is forwarded out through all the ports except the one on which it was received. If the destination address is found in the cache, the packet is forwarded only through the appropriate port—however, if the “appropriate port” is the one on which the packet was received (meaning that the packet was for transmission between nodes on a single LAN segment), the packet is dropped.
The effect of this functionality is that the bridge can learn MAC addresses, and does not require configuration. For example, consider that bridge 21 has just been put into place, without knowledge of any node addresses. Say that the first packet sent is from node A to node B. This packet will be received by the bridge 21 through the port 25. The bridge 21 will then store in its cache the MAC address of node A, which is in the source address field of the packet, together with the datum that this address is accessible through the port leading to LAN segment 22. The packet will then be forwarded on all other ports (in this case, the port 26 leading to LAN segment 23), as the bridge will have no record of the address of node B in its cache—in this case, this communication is unnecessary for receipt by node B, as node B is on the same LAN segment as node A. Say that the next packet is sent by node D to node A. The packet will be received by the bridge 21 through the port 26 corresponding to LAN segment 23, and the MAC address of node D and the datum that this address is accessible through the port 26 leading to LAN segment 23 are recorded in the bridge cache. The destination address, that of node A, is already in the bridge cache. The bridge 21 will thus transmit the packet out through the port 25 connecting to LAN segment 22, and would not transmit it through any other port. If the next packet is from node B to node A, the bridge 21 will capture the relevant data for node B in the cache—it will also know from the cache that node B and node A are on the same LAN segment 22, and hence will not forward the packet at all.
The bridge has considerable advantages: it requires (in its basic operation) no configuration, as it can operate immediately and learn the information it requires to operate with full efficiency, and it is transparent to the nodes (in that the node does not perceive any difference between communication on its own LAN segment and communication through the bridge to another LAN segment). Such a bridge does however rely for its operation on similar MAC level addressing on each LAN segment, as otherwise messages forwarded across the bridge will be unintelligible. Many types of bridge design have been proposed, though alternative designs differing from that described above do not fall within the IEEE 802.1d standard One particular design was proposed in RFC 925 by J. Postel of ISI. The RFC 925 scheme proposes bridging between LAN segments, but storing Internet (IP) addresses, rather than simply MAC level addresses, in the bridge and using network layer protocols to effect bridging. A conventional bridge is a more effective choice than an RFC 925 bridge for connecting LAN segments of similar type locally because use of a network protocol introduces additional complexity and because an IEEE 802.1d bridge can easily be implemented in hardware alone: for more complex networks, the effective choice was found to be routing (as discussed below). The RFC 925 scheme has in consequence not been applied in any standard.
Where the LAN segments are of different network types (or where the network is complex), the current general approach is to connect at the network layer level, rather than at the data link layer level. This is done by means of a router. Connection between LAN segments of different types using a router is shown in FIG. 3.
FIG. 3 shows connection of LAN segments 32, 33 of different network types by means of a router 31. Each LAN segment has a number of nodes 34. At the network layer, the protocol most commonly used is Internet Protocol (IP). Each node 34 has an IP address. An IP address has two parts: a network component and a host component. Each node on a LAN needs to have the same network component: consequently nodes A and B have the same network component “2”. The router 31 also needs to have an P address for it to be able to send and receive messages, and for the router 31 to communicate as part of LAN 32, it needs to have an address with the same network component as the nodes in LAN 32. However, the router 31 also needs to communicate as a node on LAN 33, so it needs a further IP address with network component “3”—the network component for all nodes on LAN 33. The router 31 hence needs to be configured with the network component associated with the LANs reachable through each of its ports.
Various possibilities exist for communication between nodes, but a normal arrangement would take the following form. Node A wishes to communicate with node B, for which it has the IP address, but not the data link level address. Node A broadcasts an ARP (Address Resolution Protocol) message on LAN 32 asking for node B (specifically, asking the node with IP address 2.0.0.2 to provide its data link layer address). Node B will reply, communication will take place, and router 31 is not involved (beyond receiving, and ignoring, the broadcast ARP message). Node D now wishes to communicate with node A. Node D will be aware that node A has a different network address, and will either be preconfigured to send its message directly to the router 31 (for whose MAC address it will send an ARP request), or may alternatively send an ARP request to which the router 31 (recognising the addressee as being on a different network) will respond. The router will in any case eventually receive a packet from D, and will then send this to the data link layer address of node A if this is already known by the router. If this is not already known the router 31 will send out an ARP request on LAN segment 32 to find the data link layer address for node A. When equipped with the destination data link layer address, the router 31 can forward packets from node D to node A.
As communication through a router is at the level of Internet Protocol (supported by both LAN 32 and LAN 33) and communication at the data link layer level is only between the router 31 (which is adapted to support both the data link layer protocols of LAN 32 and LAN 33) and the individual nodes, communication between nodes on different types of LAN segment is possible. However, router 31 requires significant configuration before use (for example, to provide it with network components for each LAN segment) and it is significantly more complex than a bridge. A further disadvantage of routing is that it is not possible to move a node from one network segment to another without reconfiguration for the node (specifically, without changing its IP address), whereas such movement between networks without node reconfiguration is generally possible for bridges (at least for movement within the same IP domain).
A bridge-like internet protocol router (BLIP) is described in European Patent Application No. 91305968.9 (EP-A2-0456201). The BLIP is devised to have a combination of bridge and router behaviours, and has the particular purpose of preventing the excess propagation of ARP requests (“ARP storm”) perceived to provide a technical problem for transparent bridges. The BLIP bases packet forwarding decisions on IP network/subnet addresses alone, and blocks propagation of ARP requests. When a source node requests a data link layer address for a node on a different segment of a LAN by means of an ARP request, the local BLIP responds with a special data link layer address. When the BLIP receives a packet with this special data link layer address, the BLIP forwards the message according to IP subnet address (essentially, it routes) along a spanning tree to other BLIPs—the BLIP at the final destination segment replaces the special data link layer address with the destination node data link layer address (directly if known, or after an ARP request on that segment). In this aspect, BLIP behaviour is router-like.
Particular difficulties are caused if a LAN segment employs a data link layer protocol adapted for dynamic addressing. Such a protocol is IEEE1394 (hereafter “1394”, more particularly as described in IEEE Standard 1394-1995, Standard for a High Performance Serial Bus) which has data link layer addressing very different from that of IEEE802.3 (hereafter “802.3”—used as a generic term for protocols of the ethernet type). 802.3 LANs use static, globally unique 48 bit MAC addresses, whereas 1394 LANs use 16 bit Node IDs which are dynamically reassigned whenever a “bus reset” occurs. A bus reset is an event typically associated with a change in the composition of a 1394 LAN, such as addition or removal of a node. A router can be used to connect an 802.3 LAN segment and a 1394 LAN segment, but the dynamic nature of the data link layer addressing demands added complexity, as the router needs resources enabling it to find the current data link layer address. A standard for the use of IP version 4 over 1394 has not currently been finalised, but is under development by the Internet Engineering Task Force (IETF). The current position, indicating the requirements that would be placed on a node in a 1394 LAN communicating under IP (and hence on a router connecting a 1394 LAN to a LAN of a different type), is set out in the IETF Network Working Group Internet-Draft 11 “IPv4 over IEEE 1394” edited by P. Johansson of Congruent Software, Inc., 3998 Whittle Avenue, Oakland, Calif. 94602, USA. This Internet-Draft is expected to be adopted as a standard in the near future, at which point it should appear as an RFC with the same title.
It would be desirable to combine the simplicity of operation, the transparency to nodes and the ability to learn (rather than requirement for configuration) of a bridge, with the ability of a router to communicate between LAN segments of different network types. This is particularly valuable for a network essentially comprising a backbone of one LAN type with a number of branches of another type (for example, an 802.3 backbone with 1394 branches) for which a router-based solution would be expensive and inconvenient to administer.